home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000436_news@columbia.edu _Wed Oct 2 10:18:26 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id KAA16365 for <kermit.misc@watsun.cc.columbia.edu>; Wed, 2 Oct 1996 10:18:26 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id KAA00049 for kermit.misc@watsun; Wed, 2 Oct 1996 10:18:23 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: 2nd post: Chars lost by DOS Ker under OS/2 during macros
  8. Date: 2 Oct 1996 14:18:03 GMT
  9. Organization: Columbia University
  10. Lines: 45
  11. Message-ID: <52ttir$otq@apakabar.cc.columbia.edu>
  12. References: <Pine.SUN.3.91.961001161758.9880A-100000@nic.cerf.net>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <Pine.SUN.3.91.961001161758.9880A-100000@nic.cerf.net>,
  16. Space Computer Corp. <spacecc@cerf.net> wrote:
  17. : I am running DOS Kermit 3.14, Patch 9, under OS/2 Warp with a FOSSIL
  18. : connection using Ray Gwinn's SIO programs.  This works fine for
  19. : "normal" usage, but while Kermit is executing the "Product" macro it
  20. : appears that the input buffer overflows, and characters are lost.
  21. : (This procedure worked perfectly when DOS Kermit was run under actual
  22. : DOS, rather than a DOS window under OS/2.)  More specifically, the
  23. : host is a VAX/VMS system, and both the host and Kermit are set for
  24. : xon/xoff flow control.  The host sends the escape sequence to cause
  25. : Kermit to execute the "Product" macro, which in this case is just "log
  26. : session file.dat", and follows this immediately with a data stream.
  27. : The beginning of the data stream is captured in file.dat, then there
  28. : is a big gap, then the rest of the data stream is captured.  A similar
  29. : thing happens when the second "Product" macro is executed.  In this
  30. : case, the host sends another escape sequence to cause Kermit to
  31. : execute the second "Product" macro, which is just "close session; run
  32. : myprogram.exe", followed by more data for the Kermit screen.  The
  33. : logging is correctly ended, myprogram.exe is correctly executed, and
  34. : the first of the data for the Kermit screen is correctly buffered (it
  35. : is received while myprogram.exe is running).  When myprogram.exe ends
  36. : and control is returned to Kermit, Kermit shows the screen data it
  37. : correctly buffered, but everything after that (about half a screen
  38. : full) sent while myprogram.exe was executing is lost.
  39. : 
  40. : One more observation which may be relevant:  When a long stream of
  41. : data is being sent to Kermit from the host, I can hit ctrl-S on the
  42. : keyboard to suspend the sending of data, but it keeps coming for
  43. : several seconds, which seems like an inordinately long time, and makes
  44. : me suspect that Kermit's xoff signals are not being sent to the host
  45. : quickly enough to prevent buffer overflow.  When I type ctrl-Q to
  46. : resume sending, the response is pretty quick, but not really
  47. : instantaneous (to the eye).
  48. : 
  49. This indicates a latency in the flow control.  It probably happens under
  50. OS/2 because there is a lot more overhead -- MS-DOS Kermit is running
  51. through a bunch of other compatibility layers, drivers, etc, that are not
  52. present when running in real DOS.
  53.  
  54. You didn't say what kind of connection you have, but assuming it's a
  55. serial one, you should try to arrange things so you can use RTS/CTS hardware
  56. flow control, which does not suffer from the latency problems of software
  57. flow control methods like Xon/Xoff.
  58.  
  59. - Frank